The Learning Curve/The Learning Curve (Weird Science, 1996).iso/computers/noahs.arc/part7

Text File | 1995-10-05 | 22.3 KB | 488 lines

  Let's stop for a minute and make ourselves a little checklist just to see
where we are in our personal computer evolution:

  - First we gawked at the screen and wondered if we'd ever figure out ANY
    of this stuff!  If you didn't then you're not a True Beginner and you
    can't join the club.

  - We settled down, read (?) the manual (??), and started double-clicking
    everything in sight.

  - We got better at moving files around with the mouse, and at one point
    swore we'd never touch the keyboard again unless we had to.

  - We actually DID something in one of our games, like actually made it to
    the next screen or something, so we're feeling VERY good.

  - We finally bought the modem and a terminal program, brought 'em home, set
    'em up, read the manual and were crushed when we realized it was full of
    that CLI garbage!

  - We close the term prog manual and pull out the DOS books we'd been
    avoiding.  Once we get the gist with the pathnames and such we actually
    start getting a little excited about using "semi-authentic computer
    language", as referred to "icon-shuffling".  We open the manual back up
    and breathe a sigh of relief..we can read it!

  - We make our first call to a BBS, thus taking our first tiny, hesitant
    step into the New Age.

  - We download oodles of files.  We save them faithfully on our neat,
    organized archive disks just like that nice Mr. BenchMaster said to do.

  - We become proficient at setting up and using our CustomBenches.  We've
    incorporated the basic gang, Conman, Select, Mackie, PrefCh and FaccII
    into the Amiga scheme of things.  We're movin' now.

  - Our fingers finally learned how to type and at one point we swore we'd
    never use the mouse again unless we had to.

  - We finally recaptured the Talisman in FaeryTale, FINALLY kicked the bad-
    ass Black Knight off his throne in Dark Castle (and WHAT was our reward?)
    bought some snazzy software like Dpaint, faithfully read the manual and
    did every tutorial and let's face it:  We're feelin' pretty good about
    the whole thing, aren't we?

                                    *

  I certainly was.  Especially about that megabyte of Ram.  Wow, sure was
nice havin' that big ol' megger of Ram around, yes indeedy!

  Just about the only thing I didn't know was what I was supposed to DO with
it.

                                    *

  I quickly found out.


  Df1 died.

                                    *

  It was a lovely service.  We all said a few words, and I put an old copy
of Starglider in its little slot, just before they closed the tiny casket.

                                    *

  The guy at the shop said the heads had come unaligned and it was history.
One drive??  Yuck!  Requester City!!  I was broke and couldn't buy a new one
just yet.  What to do??  The answer was to load a bunch of the stuff I nor-
mally needed off the Bench into Ram, basically move the Bench to Ram, and
then "CD Ram".  That way I could use df0 like df1, as the "remote" drive, and
control it from Ram, instead of from df0.

  This is something you HAVE to try.

  Put a copy of BareBench in df1, pull down the Rename menu and rename it to
RamBench.  That's the disk we'll use for this next section, so boot it up.

                                       *

  Everything in the s, devs and libs directories and about half the c direc-
tory should just about do it, together with any special-purpose tools
you might need.  If you've got the meg then you've got plenty of room to
spare, so start the st-seq off with the following.  On our regular Bench
we'll make this one of our Select files in the s dir:

      SetPatch >nil:             ;always this first
      AddBuffers/FaccII: 100     ;definitely this next

      MakeDir Ram:c              ;makes c directory in Ram.
      MakeDir Ram:devs           ;makes devs dir in Ram
      MakeDir Ram:libs           ;makes libs dir in Ram
      MakeDir Ram:s              ;makes s dir in Ram

      Copy c/Assign Ram:c        ;copies misc c commands to Ram:c, add any
      Copy c/CD Ram:c             others you want
      Copy c/Copy Ram:c
      Copy c/Delete Ram:c
      Copy c/Dir Ram:c
      Copy c/e Ram:c
      Copy c/EndCLI
      Copy c/Echo Ram:c
      Copy c/Ed Ram:c
      Copy c/Execute Ram:c
      Copy c/f Ram:c
      Copy c/MakeDir Ram:c
      Copy c/Path Ram:c
      Copy c/Run Ram:c
      Copy c/RunBack Ram:c
      Copy c/Type Ram:c

      Copy df0:devs Ram:devs all         :copies devs dir to Ram:devs
      Copy df0:libs Ram:libs all         ;copies libs dir to Ram:libs
      Copy df0:s Ram:s all               ;copies s dir to Ram:s

      Copy Utilities/DU-VI Ram:  ;Copy your DU and any other special
                                  tools you might need.  Copy the .info
                                  files too, if you want the icons

      Assign c: Ram:c
      Assign devs: Ram:devs
      Assign libs: Ram:libs
      Assign s: Ram:s


  The other RamBench directories, like the fonts, will still be in the paths,
remember, but only available when the RamBench disk is in a drive.  If you
moved Notepad to Ram, for instance, when you fired it up it would seek the
fonts dir, and you'd get a requester if RamBench wasn't in one of the drives.

  If you put the above at the beginning of the st-seq there'll be commands
like LoadWb and SetClock that will be "unknown commands", as by that time
you've already assigned c to Ram:c and the commands aren't there.  Just draw
out the whole pathname, like "df0:c/LoadWb", and everybody'll be happy.

  I included the EndCLI and Execute commands, as well as the "e" and "f"
commands, as I only use the "e" and "f" at the console; I always spell them
out in a scriptfile.

  You'll run into snags here and there when you've got things assigned to
directories on other devices, but hey, that's just part of what keeps it
all so dang interesting.  That's why I moved the devs, s and libs dirs over
to Ram also, to help keep the snags at a minimum.  You don't need all of the
libs and devs, of course, so you could just individually copy over the files
you think you'll need instead of using the "all" option.

  This still isn't quite good enough, though.  Having all those juicy
commands and libs and stuff in Ram is nice, but we still need to BE some-
where, i.e. a CLI window.  So we do something like this:


               CD Ram:
               NewCLI con:000/336/318/064/CD-RAM
               CD df0:
               NewCLI con:321/336/318/064/CD-DF0


  If you're using non-Interlace mode, use: 000/155/319/045/CD-RAM
                                           322/155/318/045/CD-DF0


  Re-boot this puppy and see what happens.  Hopefully everything will go
as planned.  You'll see less memory available at the top of the screen as Ram
has now got a bellyfull of goodies   If you type "CD" in the left CLI window
you should get a "Ram:" back, and in the right window the name of the disk
currently in df0.

  You'll also put those NewCLI commands on your regular Bench.  You won't
have anything in Ram, but you'll still want the window available.

  You'll have a blast with ol' RamBench, but keep it on a separate disk for
now.  We're still writing files to the s and devs dirs, and if they're
assigned to Ram, then we're writing files to Ram, which means bye-bye when
the computer's turned off.  When you're using the RamBench you have to
remember to draw out the full pathname, "df0:s/xx", so it won't write to Ram.

  Now you need a small scriptfile in s in case you need to get the memory
back to run some big graphics thing or whatever.

  Type "Ed s/dr" (for Delete Ram).  In the Ed box type

                           Assign libs: df0:libs
                           Assign devs: df0:devs
                           Assign s: df0:s
                           Assign c: df0:c
                           Delete Ram:#? all quiet
                           Echo "That's it, Boss!"

That last line, of course, MUST be in the scriptfile for it to work.  Save
that guy, and the next time you need the Ram back, type "f dr" and there it
is.  You can also have a scriptfile to reload all that stuff back in, as
well.  Just take that whole block of Copies and Assigns in the st-seq and
WriteBlock that sucker to the s directory.  Call it "lr" for Load Ram.

  Next, presuming you have FaccII running, you'll want a scriptfile to give
you back both the Ram and what FaccII's hogging.  Use the same file as above,
add a "Fac -q" and call it as "m", for Mem.

  If you ARE into graphics, then at times you may be grasping for every
byte of memory possible, and wondering why they can't have a simple UN-LoadWB
command.  I'll get to memory recovery in a few minutes.

  For your regular Bench, your scriptfile "dr" will just read "Delete
Ram:#? all", and your "m" file will have the "fac -q" tagged on.

  The basic idea of the Shell program and putting all the commands into what
they call Residence is just another way of putting them into memory for
immediate access, and you'll have fun with both RamBench and mini-versions
of it, just putting some c stuff in Ram, just the DU, whatever.  You can
use another Select in the RamBench Select scriptfile to let you choose just
what stuff you want dumped into Ram.

  And by the way, if you've done all the above, then congratulations: you
are now "CD Ram", another evolutionary step along the way.

  AND you saved the price of a new disk drive!

                                       *

  The next step after that would be to dig up the "Rad:" device from a BBS or
Fish disk, and use that, instead.  It's a "recoverable Ram", so (in theory)
your files will still be there in memory after you reboot, saving you the
re-load time.

                                       *

  Okay, reboot your regular Workbench.  Copy any pertinent files over from
RamBench's s dir, and edit the st-seq to add the NewCLI commands.

  Amiga 2000 owners, you may gleefully skip the entire next section.  Hey,
you paid the big bucks, this is your due.

                                       *

  The absolute most memory you can get is to rename or delete the st-seq
and reboot.  At that point you're seeing what the computer sees as it tries
to find "startup-sequence" in the s dir.  If you want to run your st-seq
step-by-step, this is the way to do it.  Just type in each line of the
st-seq one by one.  If there's a snag you haven't been able to unravel,
you'll find it now.

  To find out how much memory you're using, and have free, type Avail.  You
can go through your st-seq step-by-step and Avail after every entry and
actually chart how much memory each command is using, if any.  It's also fun
to Runback PerfMon (off Extras) and SysMon (off FaccII) at the very beginning
of the st-seq just to watch the programs gobble up the memory.

  You don't need to rename or delete the st-seq to be here in this bare-
bones environment; you can make this one of your Select files, this one
reading "CLI" and that's all.  You'll be in a "proper" DOS window with a
little more memory being used than the first way.

  Your file "mm" (for MaxMem) would read something like this:

      Echo "Please remove disk from df1"      ;gets back a bunch more bytes
      Echo "Please close all windows"         ;lotsa graphic bytes in windows

      Delete Ram:#? all quiet   ;cleans out Ram
      Fac -q                    ;turns off FaccII

      FastFonts -n              ;quits FastFonts
      InstallBeep -quit         ;turns off PlayBeep
      Mackie -q                 ;turns off Mackie

      Lace                      ;non-Interlace uses a bunch less graphics mem
      SetPrefs Nolace           ;non-Interlace colors
      Wait 2                    ;to let Lace do its thing and let everybody
                                 else catch their collective breath

      Sweep or Flush            ;cleans unused libs, etc, out of memory

      Echo "That's all she's got, Boss!"


  A few mentions on the above:

  We have in our s directory that "m" file for the deleting Ram and quitting
FaccII, so we could "Execute s/m" in place of those two lines. (or even
"f s/m", but it's better to write it out..not only for the computer's sake
but for glancing back over it in the future)  It also saves a bit of time
as it doesn't have to read the Execute command or the scriptfile.

  The -n option for the FastFonts command just removes the fast text, not
the new fonts, but 99 percent of the memory comes back.  Use the command
"FastFonts -quit" to get back the default fonts...AND 72 more bytes!

  I make light of the "72 more bytes", but as I mentioned earlier, memory
recovery is real serious business; there's no "close enough" when it comes
to what a program needs to run.  If it needs 287,539 bytes of FastMem and
you've only got 287,527, well, that's just tough.  And a program with, like,
audio tracks may actually run, but there won't be enough for the audio, so
you won't hear anything...and may not ever know it was there in the first
place!

  As far as removing df1's disk, a program might actually need the extra
bytes you get back, but once the program's loaded you can usually re-insert
the disk.  DPaint in 16-color hi-res serves as an example.

  The drive just sitting there diskless also uses up memory, which is one of
the reasons you never quite get near that magic 1,000,000 mark.  One game,
Destroyer, actually needs you to disconnect the drive to play it on a 512
machine.  This is not only rude, but unethical, in the sense that one of the
Big No-No's is not to plug and unplug the big cables any more than you have
to, just because you'll start wearing out the pin sockets.

  You can move an icon out of a window to the Workbench screen and close the
window behind it for a few more bytes.  If it's a scriptfile (Project) you
can activate the icon first and then close the window, but don't do it if
it's a tool..they don't like it.  Move the icon out of the window first,
then close it, for a few more precious graphic bytes.

  Libs that are called up also account for some memory loss, sometimes
permanently.  Jot down your memory available, pop up the Calculator and
close it again..surprise, the Calculator has loaded the mathieeedoubbas-
.library into memory and you've just lost two thousand bytes!  This is what
Sweep is for.  You want to see a real demo of Sweep, Say something (calls up
translator.lib and narrator.dev), see what you lose, then gain back with
Sweep.  Some memory, alas, is gone forever once used, like the first time
you open a window after booting up.  Close the window and notice you didn't
get it all back, like you will when you open and close future windows.
That's the icon.library being permanently stored in memory.  All kinds of
things get stored, like the printer.device when you use the printer and the
serial.device when you fire up a terminal program.

  I point this out for a few different reasons.  You might have some large
graphics tool that was running fine before and now won't, possibly because
you tapped into a lib or dev doing something else and permanently lost some
memory.  And sometimes a program will mess up the lib or device access for
another program.  Programs with audio in them seem particularly sensitive to
this.

  Well, that's it for memory recovery.  There are other odd tips and tricks,
like a program uses a little less memory if you type just the name rather
than Run it, and a "Path reset" gets a few bytes back, but hunting down that
elusive byte is just part of the fun.  Who knows?  You might make some
unique discovery just farting around that'll make BBS history.  Tune in
next week for...The Search For UnLoadWb!

  By the way, you think YOU got memory problems..pity us poor hard drive
owners.  Not only do BindDrivers and Mount suck up their fair share, but the
ton of Assigns and Paths don't help either.  And then on top of that, we're
trying to run these huge games out of them that were designed to be run
straight off the disk without ANY LoadWb business or non-turnoffable sub-
routines or anything, so let's have a little sympathy where it counts...

  Hey, thanks.  We appreciate your gesture.

                                       *

  I haven't mentioned printers, by the way, because there's really not a
heck of a lot to say about them.  They either work or they don't. :)

  If you want to copy every filename on the Workbench to the printer, type
"Dir >prt: all".  If you want all of df1's filenames copied to the printer
type "dir >prt: df1: all".  Sometimes "par:", which directs the output
straight to the parallel port, works better than "prt:", which uses the
Prefs printer settings.

                                       *

  Well, how 'bout an example of a "sub-scriptfile", or whatever you want to
call it?  I'm sure the books have a name for it but nothing springs to mind.
I call it a "sidebar" file which, at least journalistically, makes sense.

  I've got a downloaded game called Blackjack.  It takes about a half a
minute to get all loaded and set up (AmigaBasic), then when it does, the
colors are...just hideous!  By rare good fortune the program allows SetPrefs
to do its thing, so I do this in the Blackjack scriptfile:

    CD dh0:Games/Misc                       ;CD to dir game is in
    RunBack -1 df0:c/Execute Blackjack.scp  ;Execute sidebar scriptfile
    AmigaBasic Blackjack-                   ;run program, no Run
    SetPrefs Inlace                         ;back to Interlace colors/pointer
                                               when program is through


  To note is using the RunBack for the execution of the sidebar.  If we'd
just Executed it, it would have frozen the scriptfile until the sidebar file
was finished, not the idea.

The sidebar "Blackjack.scp" is two lines:

    Wait 38                       ;waits until program is loaded
    SetPrefs Blackjack.pref       ;sets colors and pointer to special
                                     Blackjack scheme

  So the sidebar scriptfile is humming along in the background, waiting 38
seconds, while the Blackjack program is being loaded.  Then the Wait command
is through and it resets the colors to the colors of my choice.

  You'll find various needs for them here and there.  Scriptfiles and sub-
scriptfiles are really what make the computer do what you want.

                                       *

  As a small sidenote, it might be mentioned that you'll hear Basic being
put down in all quarters, but if Blackjack had been written in code or
something, it wouldn't have allowed us to alter the color scheme to our
liking.  Just thought it ought to be mentioned.  Ever own a '63 Bug?

                                       *

  Let me give you two examples of the FailAt command.  It can really do
wonders.

  1. If you have "Delete FileX" in a scriptfile, and the file isn't there,
the failed Delete command will stop the scriptfile, with a "return code of
20".  If you put a "FailAt 25" BEFORE the Delete command, the scriptfile will
continue.  The FailAt command only works on the command following it.  In the
stock st-seq, there's a FailAt before the SetClock command, in case you
didn't have the FastMem pack (with system clock) and if failed.

  You WANT, by the way, such commands as Delete to fail when they can't
perform correctly.  It allows you to make a choice at that point and do one
thing or another, in conjunction with the "If warn" parameter.  The 2.x/3.x
commands DON'T fail now, for some odd reason, which really messed that
"choice" business up.

  2. Let's say you're running OS 1.3, but you have a 2.x kickfile you want to
use at times.  Near the beginning of your st-seq, you'd have:

FailAt 25
Version                     ;the 2.x Version command, not the 1.3
If warn                     ;the 2.x Version fails, issuing a "warn".  This
<1.3>                       ;tests for the "warn".
<commands>
<go>
<here>
Else
<2.x>
<commands>
<go>
<here>
EndIf

  Catch that?  If you're in 1.3, the 2.x Version command fails, issuing an
error code (the "warn"), which the If asks about.  In this case, there's a
"warn", so the 1.3 commands get run.  If you were under 2.x, the Version
command wouldn't have failed and the If would have skipped down to the
"Else", and run the 2.x commands.  You can also use the SetPatch command
instead of the Version command.

                                      *

  I told you before that if you were very very good I'd tell you where the
Secret Passageway in Dark Castle was...and this shall be the FIRST time The
BenchMaster has let one of the Great Secrets be told...but told it shall be,
as reward for your having accomplished so much of this fine tutorial.  And
you only fell asleep in class three times!

  Boot up the game, Beginner level.  Enter door #3.  Scoot up the ropes to
that top-left platform.  See the EDGE of the ledge up to your right?  Ah ha!
Jump up to it and you end up on the rope, probably being bitten by a rat.
The trick is to get as close, and I mean AS CLOSE, to the wall as possible,
turn around, and THEN jump up to the ledge.  Wow!  You might, of course, want
a little Shield or Fireball here as I believe we're expecting a visit from
an old friend about now...

  The reason we're in Beginner mode is because, as you MAY know, when you
get to the higher levels you bonk your head when you walk into a wall.
You can do it in all three levels, it's just much easier at Beginner.  It's
a very light finger action, obviously, that's needed, but you'll get it.
I've found that if I jump up on the rope, climb to the top then jump back
off, the spot that it leaves me in gives me the best chance to scoot right
up to the wall and stop.  There are two okay spots; with his face dead flush
against the wall and one pixel over to the right.  A game glitch?  Hey, who
knows, right?  I've found lots of "strange" things in the better games and
don't have any idea if they're glitches or not.  Go back and forth between
Shield 3 and 4 and it keeps giving you points/lives.  BUT only if you kill
all the bats in #4 first! (you only have to do it once).  It doesn't do
that between any other screens, far as I know.  Getting back to the Secret
Passageway, the questions are these:  Why WOULDN'T an old castle have a
secret passageway?  And...would it have more than ONE??  <wink>

  Update Note:  Well, I already discovered the Secret Window in Beyond
Dark Castle!  West Tower Wall, cliff on the left, toes overhanging edge,
about a third of his foot.  NO range for error, only works in one spot, very
hard to do.  Also works in the Practice mode; screen kind of goes BLINK! and
starts over.

  Have fun with the games!  Explore everything!

                                       *